👋 Hi team — this is an architectural suggestion, not a finished feature.
I'm opening it as a draft to spark discussion. Please treat the code as a reference
implementation to make the idea concrete, not as something ready to merge.

The suggestion

Replace all 54 logstash-filter-*-guardium plugins with a single generic plugin
where each datasource is a thin parser class (or ideally just a config file).

Every filter plugin in this repo is ~95% identical boilerplate. The only unique part
is the 50–150 lines of parsing logic per datasource. That boilerplate is copy-pasted
54 times, which means:

• A security fix must be applied to 54 files
• Adding a new datasource requires scaffolding a full Logstash plugin (~500 lines, new gem)
• 54 separate gems to build, test, and ship

What the proposal looks like

Before (54 plugins, each with its own gem):

filter { mysql_filter_guardium {}    }
filter { mongodb_guardium_filter {}  }
filter { guardium_snowflake_filter{} }

After (one plugin, datasource selected via config):

filter { guardium_universal_filter { datasource => "mysql"     } }
filter { guardium_universal_filter { datasource => "mongodb"   } }
filter { guardium_universal_filter { datasource => "snowflake" } }

Adding a new datasource would go from ~500 lines + new gem → ~100 lines, no new gem.

What's in this PR

• logstash-filter-guardium-universal/ — a working reference implementation
• ARCHITECTURE.md — full design rationale, old-vs-new diagrams, migration strategy, and open questions for the team
• MySQL fully migrated as a concrete example; MongoDB and Snowflake as thin connectors

Open questions for the team

• Is this direction aligned with the project's goals?
• Should IGuardiumParser live in common to allow independent parser JARs?
• Should simple datasources eventually be driven by YAML config files, with Java only for complex ones?

Happy to iterate on the design or answer any questions. Thanks for your time!

— @haimofergmail